Use case: use Debian Stable as an environment to run amd64 development machines
to develop Qt applications for Raspberry Pi or other smallish armhf devices.
Qt Creator is used as Integrated Development Environment, and it supports
cross-compiling, running the built source on the target system, and remote
debugging.
Debian Stable (vanilla or Raspbian) runs on both the host and the target
systems, so libraries can be kept in sync, and both systems have access to a
vast amount of libraries, with security support.
On top of that, armhf libraries can be installed with multiarch also in the
host machine, so cross-builders have access to the exact same libraries as the
target system.
This sounds like a dream system. But. We're not quite there yet.
cross-compile attempts
I tried
cross compiling
a few packages:
$ sudo debootstrap stretch cross
$ echo "strech_cross" sudo tee cross/etc/debian_chroot
$ sudo systemd-nspawn -D cross
# dpkg --add-architecture armhf
# echo "deb-src http://deb.debian.org/debian stretch main" >> /etc/apt/sources.list
# apt update
# apt install --no-install-recommends build-essential crossbuild-essential-armhf
Some packages work:
# apt source bc
# cd bc-1.06.95/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
dh_auto_configure -- --prefix=/usr --with-readline
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\$ prefix /include --mandir=\$ prefix /share/man --infodir=\$ prefix /share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\$ prefix /lib/arm-linux-gnueabihf --libexecdir=\$ prefix /lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --host=arm-linux-gnueabihf --prefix=/usr --with-readline
dpkg-deb: building package 'dc-dbgsym' in '../dc-dbgsym_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'bc-dbgsym' in '../bc-dbgsym_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'dc' in '../dc_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'bc' in '../bc_1.06.95-9_armhf.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../bc_1.06.95-9_armhf.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source --after-build bc-1.06.95
dpkg-buildpackage: info: binary-only upload (no source included)
With
qmake based Qt packages,
qmake is not configured for cross-building, probably because
it is not
currently supported:
# apt source pumpa
# cd pumpa-0.9.3/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -Wl,-z,now"
"QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now" QMAKE_STRIP=: PREFIX=/usr
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qmake': No such file or directory
debian/rules:19: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
With
cmake based Qt packages it goes a little better in that it finds the
cross compiler, pkg-config and some multiarch paths, but then it tries to run
armhf
moc, which fails:
# apt source caneda
# cd caneda-0.3.0/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_SYSTEM_NAME=Linux
-DCMAKE_SYSTEM_PROCESSOR=arm -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc
-DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g\+\+
-DPKG_CONFIG_EXECUTABLE=/usr/bin/arm-linux-gnueabihf-pkg-config
-DCMAKE_INSTALL_LIBDIR=lib/arm-linux-gnueabihf
CMake Error at /usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message):
The imported target "Qt5::Core" references the file
"/usr/lib/arm-linux-gnueabihf/qt5/bin/moc"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"
but not all the files it references.
: Although I improvised a chroot to be able to fool around with it, I
would use
pbuilder or
sbuild to do the actual builds.
Helmut suggests
pbuilder --host-arch or
sbuild --host.
Doing it the non-Debian way
This guide in the meantime explains how
to set up a cross-compiling Qt toolchain in a rather dirty way, by recompiling
Qt pointing it at pieces of the Qt deployed on the Raspberry Pi.
Following that guide, replacing the
CROSS_COMPILE value with
/usr/bin/arm-linux-gnueabihf- gave me a working qtbase, for which it is easy
to create a Kit for Qt Creator that works, and supports linking applications
with Debian development packages
that do not use Qt.
However, at that point I need to recompile all dependencies that use Qt myself,
and I quickly got stuck at that monster of
QtWebEngine, whose sources embed the whole of
Chromium.
Having a Qt based development environment in which I need to become the
maintainer for the whole Qt toolchain is not a product I can offer to a
customer. Cross compiling
qmake based packages on stretch
is not currently
supported, so at the moment I had to suggest
to postpone all plans for total world domination for at least two years.
Cross-building Debian
In the meantime, Helmut Grohne has been
putting a lot of effort
into making Debian packages cross-buildable:
helmut> enrico: yes, cross building is painful. we have ~26000 source
packages. of those, ~13000 build arch-dep packages. of those, ~6000 have
cross-satisfiable build-depends. of those, I tried cross building ~2300. of
those 1300 cross built. so we are at about 10% working.
helmut> enrico: plus there are some 607 source packages affected by some 326 bugs with patches.
helmut> enrico: gogo nmu them
helmut> enrico: I've filed some 1000 bugs (most of them with patches) now. around 600 are fixed :)
He is doing it mostly alone, and I would like people not to be alone when they
do a lot of work in Debian, so
Join Helmut in the effort of making Debian cross-buildable!
Build any Debian package for any device right from the comfort of your own work computer!
Have a single development environment seamlessly spanning architecture
boundaries, with the power of all that there is in Debian!
Join Helmut in the effort of making Debian cross-buildable!
Apply here, or join #debian-bootstrap on OFTC!
Cross-building Qt in Debian
mitya57 summarised the situation on the KDE team side:
mitya57> we have cross-building stuff on our TODO list, but it will likely require a
lot of time and neither Lisandro nor I have it currently.
mitya57> see https://gobby.debian.org/export/Teams/KDE/qt-cross for a summary of
what needs to be done.
mitya57> Any help or patches are always welcome :))
qemu-user-static
Helmut also suggested to use qemu-user-static to make the host system able to
run binaries compiled for the target system, so that even if a
non-cross-compiling Qt build tries to run
moc and friends in their target
architecture version, they would transparently succeed.
At that point, it would just be a matter of replacing compiler paths to point
to the native cross-compiling
gcc, and the build would not be slowed down by
much.
Fixing
bug #781226 would help in
making it possible to configure a multiarch version of qmake as the qmake used
for cross compiling.
I have not had a chance of trying to cross-build in this way yet.
In the meantime...
Having qtcreator able to work on an amd64 devel machine and deploy/test/debug
remotely on an arm target machine, where both machine run debian stable and
have libraries in sync, would be a great thing to have even though packages do
not cross-build yet.
Helmut summarised the situation on IRC:
svuorela and others repeat that Qt upstream is not compatible with Debian's multiarch thinking, in that Qt
upstream insists on having one toolchain for each pair of architectures,
whereas the Debian way tends to be to make packages generic and split stuff
such that it can be mixed and matched.
An example being that you need to run qmake (thus you need qmake for the
build architecture), but qmake also embeds the relevant paths and you need to
query it for them (so you need qmake for the host architecture)
Either you run it through qemu, or you have a particular cross qmake for your
build/host pair, or you fix qt upstream to stop this madness
Building qmake in Debian for each host-target pair, even just limited to
released architectures, would mean building Qt 100 times, and that's not going
to scale.
I wonder:
- can I have a
qmake-$ARCH binary that can build a source using locally
installed multiarch Qt libraries, do I need to recompile and ship the whole
of Qt, or just qmake?
- is there a recipe for building a cross-building Qt environment that would be
able use Debian development libraries installed the normal multiarch way?
- we can't do perfect yet, but can we do better than
this?
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
This is the first monthly report in 2023.
Almost a year ago I added a script made by 
Welcome to gambaru.de. Here is my monthly report (+ the first week in November) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
What happened in the